home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 951 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.5 KB

  1. Path: fido.asd.sgi.com!austern
  2. From: martin@kcbbs.gen.nz (Martin D Kealey)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Referencing pointers after delete
  5. Date: 03 Apr 1996 09:20:32 PST
  6. Organization: -
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <m0u4G70-000GcEC@7.kurahaupo.gen.nz>
  9. NNTP-Posting-Host: isolde.mti.sgi.com
  10. Content-Type: text/plain; charset=ISO-8859-1
  11. Content-Transfer-Encoding: 8bit
  12. X-Original-Date: Wed, 3 Apr 1996 12:07:45 +1200 (NZST)
  13. In-Reply-To: <199604010435.UAA16550@corvette.ucr.edu> from "Tom Payne" at Mar 31, 96 08:35:28 pm
  14. X-Mailer: ELM [version 2.4 PL24]
  15. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  16.     iQBVAwUBMWKzYUy4NqrwXLNJAQFXqwH/eYjKJH0y7mb0J79PTFpuN3rpT/LXPafB
  17.     cVJuUGB+JC1XWKse4lP5YzuSc94jWzuWAtW1cE9QEwYT7hYvlwMY5A==
  18.     =++Oq
  19. Originator: austern@isolde.mti.sgi.com
  20.  
  21. It seems that I didn't quite make myself clear; therefore I've
  22. copied this to std-c++ in case anyone else is similarly confused.
  23.  
  24. I wrote:
  25.  
  26. > > Consider this implementation ... where every object contains ...
  27. > > task pointer
  28.  
  29. > > Now, if we run out of normal registers and it is necessary to
  30. > > spill the "current task" register, its value can be reloaded
  31. > > through any register pointing at an object (say because register-
  32. > > indirect might be faster than absolute addressing). The compiler
  33. > > writer knows this will only be done if a valid pointer value is
  34.     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  35. > > already in a register (and calling delete will invalidate the
  36. > > register), since it would be more economical to obtain the value
  37. > > some other way if a pointer to it isn't available).
  38.  
  39. Tom Payne <thp@cs.UCR.edu> wrote:
  40.  
  41. > If that pointer is chosen statically, one can correctly anticipate
  42. > which pointer it will be and concoct a valid program that deletes the
  43. > pointer's referent prior to the restoration of current-task:
  44. >
  45. >         Widget* p = anticipated();    // Referent gets deleted
  46. >         delete p;                     // via the alias p.
  47. >         // Code to cause current-task to be spilled and restored.
  48.                                                       ^^^^^^^^^^^^
  49.  
  50. This misses a critical point -- "Code to cause current-task to be
  51. spilled and restored" must explicitly refer to "p" as a non-lvalue
  52. for the value of p to be involved in the reload; see later for the
  53. explanation.
  54.  
  55. > If, for instance, delete zeros out the deleted object, this valid
  56. > program will crash and burn.  It seems to require run-time checking
  57. > (and overhead) to avoid this.
  58.  
  59. Only if the risk of aliasing is undetectable at compile time; in
  60. fact even a conservative approach can guarantee non-aliasing in
  61. some cases -- but see later.
  62.  
  63. > The crashing and burning discussed above is not a result of the
  64. > program reading an invalid pointer but of the implementation
  65. > dereferencing one and using data from its deleted referent.
  66.  
  67. In a word, no.
  68.  
  69. I said explicitly that if the pointer was deleted then the
  70. register would be invalidated so that it would NOT be used.
  71.  
  72. If the program never mentions p again, it won't crash (*) because
  73. the value in the register has been invalidated; if it does use the
  74. value of p, then it doesn't meet the standard's current
  75. requirement.
  76.  
  77. (*  At least, it won't crash because of this potential problem; I
  78.     can't speak for whatever other bugs the program might have.)
  79.  
  80. > How do you know that value is "valid"?  Perhaps, we've invalidated it
  81. > by deleting its referent through another pointer to the same object?
  82.  
  83. *Sigh*  This is not supposed to be a complete description, just an
  84. example.  So ok, change it to invalidate all registers which
  85. contain pointers to the same type as p, not just the single
  86. register which contains the value of p.  Also, *all* registers are
  87. invalidated over (non-inline) function calls, or any other time
  88. we're not 100% sure what they might contain.
  89.  
  90. I think now that accidental use of register aliasing is not
  91. possible -- one has explicitly to use p (or an alias for it) as a
  92. non-lvalue in the source code to cause this effect, and that means
  93. the program is non-conforming.
  94.  
  95. I know this is a perverse implementation that does some pretty
  96. fantastic peephole optimising without bothering to do any dataflow
  97. analysis, but that alone doesn't currently make it non-conforming.
  98.  
  99. - Martin.
  100. ---
  101. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  102.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  103.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  104.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  105.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  106. ]
  107.